Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

Using the Connection Manager

The Configuration File Manager starts the Connection Manager during the startup process. In fact, the Configuration File Manager assumes that the Connection Manager is the first manager specified in the managers section of the ICFCONFIG.XML file.

The Connection Manager is a universal API that wraps the different types of services so that developers can connect to the services using a standard API.

To provide the specific communication to each type of service, there must be a Service Type Manager procedure for the service. The framework provides a Database Manager, an AppServer Manager, and a JMS Manager for you to take care of communicating with their respective service types. To make a connection to the service, the programmer simply makes a call to the Connection Manager with the name of the service to be connected.

The service types and service connection data are all stored in the database, and those that are required at startup are written to the ICFCONFIG.XML file. The Configuration File Manager takes care of calling the Connection Manager to establish the initial connections. The service types are maintained in the Service Type Control window under the Session menu, as shown:

When the Session Manager itself starts up, it obtains a complete list of all the services and service types that the session has access to and provides these to the Connection Manager. The Connection Manager only connects to these services upon request.

To communicate with a service:

Register the Service Type Manager.

To register the Service Type Manager of the service, the application must start the Service Type Manager as a persistent procedure, and then make a call to the procedure setServiceTypeManager in the Connection Manager. Remember that there is no global variable for the Connection manager, so you must run getManagerHandle to obtain it, as shown:

hConnection = DYNAMIC-FUNCTION(‘getManagerHandle’, ‘ConnectionManager’). RUN MyService.p PERSISTENT SET hMyService. RUN getServiceTypeManager IN hConnection (INPUT hMyService).

Once the Service Type Manager has been registered, any calls that are made to the Connection Manager are diverted to the appropriate Service Type Manager.

Register the service.

To register a service, the application must make a call to registerService in the Connection Manager, passing the handle to a buffer that contains the related data, as shown:

RUN registerService IN hConnection ( INPUT bMyService).

Connect to the service.

To connect to a service, the application must call connectService in the Connection Manager, passing the name of the service to be connected, as shown:

RUN connectService IN hConnection (‘MyService’).

Disconnect from the service.

To disconnect a service, the application calls disconnectService in the Connection Manager, passing the name of the service to be disconnected, as shown:

RUN disconnectService IN hConnection (‘MyService’).

Interact with the service.

Calls to interact with a service are summarized as follows:

lConnected = DYNAMIC-FUNCTION(‘isConnected’ IN hConnection, pcServiceName AS CHARACTER).

cServiceHandle = DYNAMIC-FUNCTION(‘getServiceHandle’ In hConnection, pcServiceName) /* Note that the handle is returned as character string */

cPhysicalService = DYNAMIC-FUNCTION(‘getPhysicalService’ IN hConnection, pcMyService).

cConnectionString = DYNAMIC-FUNCTION(‘getConnectionString’ IN hConnection, pcMyService). /* This returns the character string needed to connect to the service */

cConnectionParams = DYNAMIC-FUNCTION(‘getConnectionParams’ IN hConnection, pcMyService). /* This returns the connection parameter string as it is stored on the database.*/